System and Method for Preventing Unauthorized Use of Digital Media

ABSTRACT

A method for protecting digital media content from unauthorised use on a client, is described. The method comprising the steps of receiving from a server on the client a list of processes, instructions, activity descriptions or data types that must not be active simultaneously with playback of the digital media content (“the blacklist”). The method further comprising checking, on the client, for the presence of any items on the list; and continuing interaction with the server, key management and playback of protected content only if no items on the list are detected on the client. A system is also described.

FIELD OF INVENTION

The present invention relates to the prevention of digital media piracy.

BACKGROUND TO THE INVENTION

Distribution of media such as films over the internet to clientcomputers is becoming more prevalent as film studios have begun toapprove the process. However, piracy in this environment is a problem.

There has been a great deal of effort directed at preventing piracy ofdistributed digital media. One approach has been for the media providerto install executable code onto the client computer that reports to themedia provider on the configuration and software running on the clientcomputer. The media provider then assesses the client computerconfiguration to determine if it poses a piracy threat. If there isperceived to be a threat, the media provider declines or stops thedownload of media to the client computer. In some cases, code or data onthe client computer is deleted or altered.

While it is important to safeguard delivered media from piracy,attention must be paid to client privacy and to the problem of falsepositives in the detection of piracy that result in subsequentalteration of the functionality of client systems. Quite apart from thepotential for actual abuse, the bad publicity that comes with anyperceived abuse on the part of the media provider can seriously affectconsumer choice For example Sony root kit, Intel P3 ID, and Media PlayerGUIDs. It is also important that anti-piracy measures do nor undulyaffect the operation of the media delivery system. In particular, antipiracy measures that take an unduly long time and so delay the deliveryof content are unattractive to users and are therefore commerciallydamaging for media providers.

The term “comprising” as used in this specification means “consisting atleast in part of”. When interpreting each statement in thisspecification that includes the term “comprising”, features other thanthat or those prefaced by the term may also be present. Related termssuch as “comprise” and “comprises” are to be interpreted in the samemanner.

As used herein the term “and/or” means “and” or “or”, or both.

As used herein “(s)” following a noun means the plural and/or singularforms of the noun.

It is intended that reference to a range of numbers disclosed herein(for example, 1 to 10) also incorporates reference to all rationalnumbers within that range (for example, 1, 1.1, 2, 3, 3.9, 4, 5, 6, 6.5,7, 8, 9 and 10) and also any range of rational numbers within that range(for example, 2 to 8, 1.5 to 5.5 and 3.1 to 4.7).

The entire disclosures of all applications, patents and publications,cited above and below, if any, are hereby incorporated by reference.

In this specification, where reference has been made to external sourcesof information, including patent specifications and other documents,this is generally for the purpose of providing a context for discussingthe features of the present invention. Unless stated otherwise,reference to such sources of information is not to be construed, in anyjurisdiction, as an admission that such sources of information are priorart or form part of the common general knowledge in the art.

SUMMARY OF THE INVENTION

It is an object of the present invention to provide an anti-piracysystem for delivered digital media that does not unduly compromiseclient privacy, or unduly compromise system performance, but thatprovides adequate protection for media providers or at least providesthe public or industry with a useful choice.

In a first aspect, the invention may broadly be said to consist of amethod for protecting digital media content from unauthorised use on aclient, comprising the steps of:

-   -   receiving from a server at the client a list of processes,        instructions, activity descriptions or data types that must not        be active simultaneously with playback of the digital media        content;    -   checking, on the client, for the presence of any items on the        list; and    -   continuing interactions with the server, key management and        playback of protected content only if no items on the list are        detected on the client.

Preferably, the step of checking comprises checking on the client forthe presence of any items on the list that are active on the client.

Preferably the step of checking further comprises, where items on theblacklist are active on the client, processing a weighting for eachactive item and determining whether the processed weightings exceed athreshold.

Preferably, the method includes the step of periodically updating thelist.

Preferably, the method is carried out as part of a session set uproutine. This can be as part of an authentication routine or any otheraccess manager protocol set up session

Preferably, the method is carried out substantially continuously.Alternatively, the method may be carried out at predetermined intervalsduring the delivery and playback of digital media content or at othertimes.

Preferably, each of the items in the list has a priority valueassociated with it.

Preferably, digital rights or decryption keys or both, required forplayback of the digital media, are delivered to the client via a server.

Preferably, the blacklist is received by the client along with thedigital rights or decryption keys or both.

In a second aspect, the present invention may broadly be said to consistin a system for protecting digital media content from unauthorised usein a client, comprising:

-   -   a blacklist server; and    -   a client connected to the server over a network;    -   wherein the blacklist server is adapted to transmit a blacklist        of threatening processes, instructions, activity descriptions or        data types to the client;    -   wherein the client is adapted to run a checking process that        checks for the presence of any items on the blacklist on the        client; and    -   wherein the client is adapted to continue interaction with the        server, key management and playback of protected content with        the server only if no items on the list are detected on the        client.

Preferably, the system further includes a digital rights managementsystem connected to the blacklist server, wherein digital rightsinformation is sent to and from the client via the blacklist server.

Preferably the system is adapted to, if items on the blacklist arepresent on the client, process a weighting for each present item anddetermine whether the processed weightings exceed a threshold.

Preferably, the client is adapted to check for the presence of any itemson the blacklist a plurality of times during playback of the digitalmedia content.

Preferably, each item on the blacklist has an associated priority value.

In a third aspect, the present invention may broadly be said to consistin a machine readable medium that provides instructions for preventingunauthorised use of digital media, which, when executed by at least oneprocessor on a client, cause the processor to perform the steps of:

-   -   receiving from a server a list of processes, instructions,        activity descriptions or data types that must not be active        simultaneously with playback of the digital media content;    -   checking, on the client, for the presence of any items on the        list; and    -   continuing interaction with the server only if no items on the        list are detected on the client.

In a fourth aspect, the invention may broadly be said to consist of amethod for protecting digital media content from unauthorised use on aclient, comprising the steps of:

-   -   receiving from a server on the client a list of processes,        instructions, activity descriptions or data types that must not        be active simultaneously with playback of the digital media        content;    -   checking, on the client, for the presence of any items on the        list.

Preferably the client ceases interaction with the server if any items onthe blacklist have been detected without passing any details relating toprocesses running on the client to the server.

Alternatively or additionally, the user might be alerted themselves.Diagnostics information could be recorded on the client and/or displayedto the user. Alternatively or additionally, diagnostics informationcould be sent to a service operator in order to assist the user.

In another aspect the present invention may be said to consist in amethod of controlling playback of digital media content on a clientcomprising: accessing a blacklist of items,

-   -   determining presence of items on the client that are on the        blacklist,    -   controlling playback of the digital media content on the client        based on the presence of items on the client.

Preferably the playback is controlled by aborting playback if at leastone item on the client is on the black list.

Preferably the blacklist comprises weightings and the method furthercomprises obtaining a weighting of items in the blacklist present on theclient, and controlling playback based on the weighting.

In another aspect the present invention may be said to consist in asystem for controlling playback of digital media content on a clientcomprising:

-   -   a blacklist of items,    -   a process for determining presence of items on the client that        are on the blacklist,    -   a process for controlling playback of the digital media content        on the client based on the presence of items on the client.

Preferably the playback is controlled by aborting playback if at leastone item on the client is on the black list.

Preferably the blacklist comprises weightings and the system furthercomprises a process for obtaining a weighting of items in the blacklistpresent on the client, and controlling playback based on the weighting.

To those skilled in the art to which the invention relates, many changesin construction and widely differing embodiments and applications of theinvention will suggest themselves without departing from the scope ofthe invention as defined in the appended claims. The disclosures and thedescriptions herein are purely illustrative and are not intended to bein any sense limiting.

BRIEF DESCRIPTION OF THE DRAWINGS

Examples of the present invention will now be described in detail withreference to the accompanying drawings, in which:

FIG. 1 is a schematic diagram of a client service system in accordancewith the present invention.

FIG. 2 is a schematic diagram showing a wider media delivery system inaccordance with a preferred embodiment of the present invention.

FIG. 3 is a flow diagram showing the steps undertaken on a client in ananti-piracy process in accordance with a non-gated example of thepresent invention.

FIG. 4 is a flow diagram showing the steps undertaken on a client in ananti-piracy process in accordance with a gated example of the presentinvention.

FIG. 5 is a block diagram of an example blacklist.

FIG. 6 is a flow diagram of a scanning process.

FIG. 7 is a block diagram of an example greylist.

FIG. 8 is a flow diagram of a greylist scanning process.

DETAILED DESCRIPTION

FIG. 1 is a schematic diagram showing a basic client/server system inaccordance with the present invention. Server 100 is connected over anetwork 110 to a client 120. The server 100 includes or is part of adigital rights management (DRM) system. The server 100 provides theclient 120 with access to digital media. The server may simply handleDRM functions or may also handle delivery of the media and encryptionprocesses as well. In a preferred embodiment, the server simply handlesDRM functions. The server includes, or is connected to, a blacklistdatabase 102. A blacklist manager 104 is connected to the blacklistdatabase, the operation of which will be described later.

The network 110 will typically be the Internet but may also includelocal area networks (LANs), wide area networks (WANs) and directconnections.

The client 120 is any client capable of playing digital media forexample a personal computer, set top box or pda. The client 120 as shownin FIG. 1 includes a media player 122, such as Real Player or WindowsMedia Player. Also running on the client, and associated with the mediaplayer 122, is an access manager 123 including a blacklist scanner 124.

The present invention provides protection against unauthorised use ofdigital media by checking the client system for threatening processes ordata types running on the client system. The blacklist database includesan updated list of threatening processes and data types. In operation,following a request from the client for digital media, the blacklistmanager 104 sends a list taken from the blacklist database 102 to theblacklist scanner running on the client over the network 110. Theblacklist scanner checks the client for the presence of any of the itemson the list running on the client. The blacklist scanner 124 can beconfigured to check particular locations on the client such as thesystem configuration data stored for example in the/etc. directory on anembedded Unix platform or the registry on a Microsoft Windows PC andtask list, or may check the entire client including the hard disk ifthere is one.

The DRM procedure, decryption key management or media download cancontinue while the scanner carries out checks. If the blacklist scanner124 detects the presence of an item on the list, the access manager 123exits and breaks the communication channel with the server 100 and allassociated processes cease.

The media player also has an embedded anti-piracy component, thedecryption plug-in library 125.

The plug-in library is associated with the access manager daemon andwhen an item on the blacklist is detected on the client 120, the plug-inlibrary acts to prevent the media player from decrypting any media filesor streams associated with the anti-piracy service. The media player isnot disabled from playing other media, only the media requested via theaccess manager daemon interface. This may be achieved by deleting thekeys necessary for decryption of the media from the plug-in library.

This scanning process can be limited to checking for items running onthe client and can be carried out at intervals during registration,secure channel set up, download and playing of digital media files. Thescanning process may be carried out on a continuous basis in thebackground and asynchronously to any other processes. The blacklisttransfer and scanning process is optionally part of the set up of asecure channel between the client and the server.

Examples of threatening processes that could be included on theblacklist are debuggers, videoframe grabbers. The list may include fileor program names, digital signatures associated with threateningprocesses, registry entries.

The list may be prioritised so that, once certain checks have been made,the media decryption process can continue while further checks are madein the background. The choice of the number of checks made before anyfurther processes can continue is a balance between providing a userfriendly system and providing security for the media.

Different levels of security may be implemented in the system of thepresent invention depending on the perceived level of threat. If at aparticular time there is known to be threatening software of a certaintype in wide circulation, the corresponding item on the blacklist can begiven high priority and checked for more frequently than during normaloperation.

Following termination of a connection with the access manager serverbecause of a detected threat, assuming the threat is no longer active onthe client, standard reconnection can occur without any detrimentalaffect on the client software. Optionally, the client may be required tore-register with the media provider if there is an increased perceivedthreat level at that time. Tamper detection is possible without anyinformation about the software or data on the client being necessaryreported to the access manager server (apart from the access managerdaemon version number).

Alternatively the required current version may be downloaded to theclient and checked.

FIG. 2 shows a complete online digital media delivery systemincorporating a system in accordance with the present invention. Theclient 120 has the same internal processes running as the clientdescribed with reference to FIG. 1. The client 120 is connected over theInternet to an access manager server 100, as described with reference toFIG. 1, as well as to a media server 220 and an encryption Key server230. The system also includes a DRM server 240 connected between the Keyserver and the access manager server 100, an Encryption server 210 forencrypting media works and creating keys connected to both the mediaserver 220 and the Key server 230, and a Subscriber Management server200 connected to the access manager server 100.

The system shown in FIG. 2 separates the delivery of media from thedelivery of decryption keys and from the delivery of rights to accessthe keys and/or the media. The process used for encryption and formanagement of the media, keys and rights is not critical to the presentinvention and so will not be described in detail here. A preferredscheme is described in U.S. Pat. No. 7,076,067, the contents of whichare incorporated herein by reference.

As shown in FIG. 2 a media provider registers a user. The SubscriberManagement system 200 stores the registration details, including theclient name, client identification, a password and billing details.

The access manager daemon requests the latest version of the blacklistfrom the access manager server 100 to be sent to the client blacklistscanner 124. This request is like a blacklist “ping” of the accessmanager server. The blacklist scanner checks the client 120 for anyitems on the blacklist that are active on the client 120.

As mentioned above, the items on the blacklist may have an associatedpriority level. The items perceived to have the greatest risk associatedwith them (typically because those items are most widespread) arechecked for first. If no items with the highest priority are detected,then the access manager daemon 123 allows further transactions toproceed with the access manager server while the lower priority items onthe blacklist are checked for. This allows the system to perform quicklyand so be user friendly, while still providing adequate protection forthe media work. In the preferred embodiment all checking is carried outin parallel with the DRM transactions.

The DRM processes and delivery of keys and the media work can proceed,as described in for example U.S. Pat. No. 7,076,067, the contents ofwhich are incorporated herein by reference. This process is used as anexample only and alternative DRM processes may be used without departingfrom the scope of the invention.

In this U.S. Pat. No. 7,076,067 the rights to receive keys are firstsent to the client from the DRM server 240 via the access manager 103.The rights to receive keys may include the URL to access the mediaserver 220, the URL to access the Key server 230 and tokens. Each tokenis single-use and is associated with a particular piece of media. Thekeys are then requested and downloaded to the client from the Key server230 and used to decrypt the encrypted media work downloaded from theMedia server 220. The blacklist may be downloaded as part of keys ortoken delivery payload.

In order to guard against threatening processes that are loaded aftersession set up with the Access Server, the blacklist scanner on theclient checks the client for items on the blacklist throughout theprocess of obtaining rights and keys and playback of the media file.Repeat blacklist scans can be performed on a periodic basis.Alternatively scanning may be done continuously and cyclically. Variousschemes may be employed using the priority levels associated with eachitem on the blacklist. For example, high priority items may be checkedevery few seconds whereas low priority items may be checked only onchannel set up. In effect, there may be several different blacklists,divided based on priority, each blacklist processed on the clientaccording to a different scheme.

The blacklist must be kept up-to-date in order to be effective. Ideally,the blacklist is updated centrally by a dedicated service and sent tothe access manager 103. The access manager daemon 123 on the client 120periodically, or based on transactions, requests an updated blacklist.This may be done as a blacklist “ping” in which the client sends theversion of the blacklist that it has to the blacklist manager 104. Theblacklist manager then returns an updated a list or a list of additionsand deletions from the list on the client 120. Alternatively, an updatedblacklist may be sent from the access manager to clients on a periodicbasis during secure connection.

FIG. 3 is a flow chart of the steps performed on the client foranti-piracy purposes in accordance with a non-gated embodiment of thepresent invention. At step 300 the client requests access to a mediafile. As part of the initial set up process described with reference toFIG. 2, at step 305 the client receives an updated blacklist from theaccess manager server. In parallel with receiving the latest blacklistthe client proceeds with the necessary DRM transaction steps 320. Thisembodiment is non-gated as the DRM checks do not have to wait for theblacklist checks, both happen in parallel.

In a first scanning step 310, the blacklist scanner checks for highpriority items on the blacklist active on the client. If any blacklisteditems are active and detected on the client at step 310 then the processincluding the DRM transaction steps are aborted at step 315.

In step 325, the blacklist scanner checks the client for lower priorityblacklist items. If any blacklisted items are active and detected on theclient at step 325 then the process is aborted at step 330.

If no blacklisted items are detected on the client at step 325 thenfurther transactions proceed at step 335. These further transactions mayinclude delivery of tokens and keys and media decryption and playbackmay begin. If playback of the media file is not complete, the client isscanned again. Step 340, the request for and/or the delivery of updatedblacklist data is shown in a dotted outline as occurring after only asingle scan of the client. However, the obtaining of an updatedblacklist may only occur daily or during set-up of the connection or atany pre-configured interval.

At step 345 the client is scanned again by the blacklist scanner in caseblacklisted items have become active following the initial scan. If anyblacklisted items are active and detected in step 345, then mediadecryption and playback is aborted at step 350. If no blacklisted itemsare active and detected in step 345, then media decryption and playbackis continued at step 355.

FIG. 4 is a flow chart of the steps performed on the client foranti-piracy purposes in accordance with a gated embodiment of thepresent invention. In this embodiment, DRM checks do not proceed untilat least some checking has been done and no blacklist items are found.

At step 300 the client requests access to a media file. As part of theinitial set up process described with reference to FIG. 2, at step 305the client receives an updated blacklist from the access manager server.In a first scanning step 310, the blacklist scanner checks for highpriority items on the blacklist active on the client.

If any blacklisted items are active and detected on the client at step310 then the process is aborted at step 315.

If no blacklisted items are detected on the client at step 310 then theclient proceeds with the DRM transactions at step 320. Typically thesefurther transactions include DRM steps. At the same time, in step 325,the blacklist scanner checks the client for lower priority blacklistitems.

If any blacklisted items are active and detected on the client at step325 then the process is aborted at step 330.

If no blacklisted items are detected on the client at step 325 thenfurther transactions proceed at step 335. These further transactions mayinclude delivery of tokens and keys and media decryption and playbackmay begin. If playback of the media file is not complete, the client isscanned again. Step 340, the request for and/or the delivery of updatedblacklist data is shown in a dotted outline as occurring after only asingle scan of the client. However, the obtaining of an updatedblacklist may only occur daily or during set-up of the connection.

At step 345 the client is scanned again by the blacklist scanner in caseblacklisted items have become active following the initial scan. If anyblacklisted items are active and detected in step 345, then mediadecryption and playback is aborted at step 350. If no blacklisted itemsare active and detected in step 345, then media decryption and playbackis continued at step 355.

If playback of the media file is not complete, the client is scannedonce again. Once playback of the media file is complete the mediaplayback process ends, in step 360, scanning may continue. FIG. 5 showsa possible blacklist and FIG. 6 shows further detail of a scanningprocess using the blacklist. This shows in more detail the scanningprocess depicted in FIGS. 3 and 4. For example, the scanning process ofFIG. 6 could be implemented in the “scan for high priority items”, step310, or the “scan for low priority times”, step 325. The blacklist 104contains a range of items, such as utilities, applications, processes,instructions, activity descriptions, data types and/or other processesthat might exist on the client. Optionally, each black list item has apriority.

With reference to FIG. 6, the scanning works as follows. The processeson the client are determined, step 60. Then the processes are comparedto the blacklist, step 61. Based on this, playback of content on theclient is controlled. If there is one or more blacklist items running onthe client, step 62, then the provision of the media is aborted, step315/330 (as per FIG. 3 or 4). If there are no blacklist items on theclient, step 62, then the playback continues.

If the blacklist contains priorities 51, then only some of the blacklistwill be compared to the processes running on the client. This willdepend on which priority items are being checked. For example, if a highpriority scan is being undertaken (such as step 310 in FIGS. 3/4) thenonly the number 1 priority blacklist items will be checked for. If a lowpriority scan is being undertaken (such as step 325 in FIGS. 3/4), theonly the number 2 priority blacklist items will be checked for. Morethan two priorities could be provided.

In an alternative embodiment, the black list comprisesratings/weightings for each item 70, such as shown in FIG. 7. A blacklist with ratings/weightings can be called a “greylist” 70—in effect, agreylist is a special case of a blacklist. A scan is conducted, whichcould be called a “greylist scan”, although more generally is stillcalled a black list scan that has further processing ofratings/weightings. Each item in the list has a rating or weighting 71.If an item in the greylist exists on the client, this will notnecessarily abort the provision of media. This greylist scan process canbe used in the place of scans of steps 310 and/or 325 of FIGS. 3 and 4.

Referring to FIG. 8, the grey list scan works in this manner. First, theitems on the client are determined, step 80. These are then compared tothe items on the greylist, step 81. If an item exists on the greylist,the corresponding rating/weighting is retrieved. The ratings/weightingsof all grey list items running on the client are retrieved and addedtogether or otherwise processed by a mathematical function to produce atotal or resultant weighting, step 82. Based on this processing,playback of content on the client is controlled. If the total weightingis above a threshold, then the provision of media is aborted, step315/330. A threshold might be 100, for example.

In this manner, the risk associated with a particular item is used indetermining whether to abort the provision of media. A single low-riskitem (e.g. Graph editor rating 10) would not be enough to reach thethreshold, and therefore there would be no abort. But, a large number oflow-risk items running on a client, or two or three high risk (e.g.screen scraper rating 50) items might be enough to breach the thresholdand trigger and abort. This approach provides a more sophisticated wayof determining when to abort the process, reducing “unwarranted” aborts.

It will of course be appreciated that any suitable rating system,threshold, and mathematical process for combing the ratings could beused for this invention.

The system and method of the present invention is equally applicable tobroadcast media as it is to downloaded (on demand) media.

The present invention offers anti-piracy protection without any questionof compromising client privacy. This makes it an attractive solution forend users. No data, apart from software version numbers and informationrequired to complete authentication, is sent from the client to theaccess manager. No executable code, which might interfere or damageexisting client systems, is downloaded onto the client afterregistration. Only blacklist data and data required for media playbackis sent from the access manager server.

The present invention provides a flexible framework for anti-piracymeasures. The level of security can be altered depending on theperceived level of threat.

The present invention can be integrated with DRM and key deliveryfunctions in a media delivery system so threats can continue to bemonitored during media playback and crucial DRM and key delivery stepscan be terminated if a threat is detected.

The system might abort a process upon determining blacklist item on theclient, or alternatively or additionally, the user might be alertedthemselves. Diagnostics information could be recorded on the clientand/or displayed to the user. Alternatively or additionally, diagnosticsinformation could be sent to a service operator in order to assist theuser in responding to detection of a blacklist item/abort.

The embodiments described comprise a blacklist that can be periodicallyupdated. Uploads of partial threats or blacklists can occur. Forexample, to advise the client about “threats” A, B, C, four messagescould be sent:

Message 1: A Message 2: B Message 3: C1 Message 4: C2

Where threat C=C1+C2

This invention may also be said broadly to consist in the parts,elements and features referred to or indicated in the specification ofthe application, individually or collectively, and any or allcombinations of any two or more of said parts, elements or features, andwhere specific integers are mentioned herein which have knownequivalents in the art to which this invention relates, such knownequivalents are deemed to be incorporated herein as if individually setforth.

1. A method for protecting digital media content from unauthorised useon a client, comprising the steps of: receiving from a server at theclient a list of processes, instructions, activity descriptions or datatypes that must not be active simultaneously with playback of thedigital media content (“the blacklist”); checking, on the client, forthe presence of any items on the list; and continuing interaction withthe server, key management and playback of protected content only if noitems on the list are detected on the client.
 2. A method for protectingdigital media content from unauthorised use on a client according toclaim 1, wherein the step of checking comprises checking on the clientfor the presence of any items on the blacklist that are active on theclient.
 3. A method according to claim 2 wherein the step of checkingfurther comprises, where items on the blacklist are active on theclient, processing a weighting for each active item and determiningwhether the processed weightings exceed a threshold.
 4. A method forprotecting digital media content from unauthorised use on a clientaccording to any preceding claim, further comprising the step ofperiodically updating the list.
 5. A method for protecting digital mediacontent from unauthorised use on a client according to any precedingclaim, wherein the method is carried out as part of a session set uproutine.
 6. A method for protecting digital media content fromunauthorised use on a client according to any preceding claim, whereinthe method is carried out substantially continuously.
 7. A method forprotecting digital media content from unauthorised use on a clientaccording to any preceding claim, wherein the method is carried out atpredetermined intervals during the delivery of digital media content. 8.A method for protecting digital media content from unauthorised use on aclient according to any preceding claim, wherein each of the items inthe list has a priority value and/or weighting associated with it.
 9. Amethod for protecting digital media content from unauthorised use on aclient according to any preceding claim, wherein digital rights ordecryption keys or both, required for playback of the digital media, arereceived by the client via a server.
 10. A method for protecting digitalmedia content from unauthorised use on a client according to claim 9,wherein the blacklist is received by the client along with the digitalrights or decryption keys or both.
 11. A system for protecting digitalmedia content from unauthorised use in a client, comprising: a blacklistserver; and a client connected to the server over a network; wherein theblacklist server is adapted to transmit a blacklist of threateningprocesses, instructions, activity descriptions or data types to theclient; wherein the client is adapted to run a checking process thatchecks for the presence of any items on the blacklist on the client; andwherein the client is adapted to continue interaction with the server,key management and playback of protected content only if no items on thelist are detected on the client.
 12. A system for protecting digitalmedia content from unauthorised use in a client according to claim 10,further comprising a digital rights management system connected to theblacklist server, wherein digital rights information is sent to and fromthe client via the blacklist server.
 13. A system for protecting digitalmedia content from unauthorised use in a client according to claim 11 or12, wherein the system is adapted to, if items the blacklist are presenton the client, process a weighting for each present item and determinewhether the processed weightings exceed a threshold.
 14. A system forprotecting digital media content from unauthorised use in a clientaccording to any one of claims 11 to 13, wherein the client is adaptedto check for the presence of any items on the blacklist a plurality oftimes during playback of the digital media content.
 15. A system forprotecting digital media content from unauthorised use in a clientaccording to any one of claims 11 to 14, wherein each item on theblacklist has an associated priority value and/or weighting.
 16. Amachine readable medium that provides instructions for preventingunauthorised use of digital media, which, when executed by at least oneprocessor on a client, causes the processor to perform the steps of:receiving from a server a list of processes, instructions, activitydescriptions or data types that must not be active simultaneously withplayback of the digital media content; checking, on the client, for thepresence of any items on the list; and continuing interaction with theserver, key management and playback a protected content only if no itemson the list are detected on the client.
 17. A method for protectingdigital media content from unauthorised use on a client, comprising thesteps of: receiving from a server on the client a list of processes,instructions, activity descriptions or data types that must not beactive simultaneously with playback of the digital media content; andchecking, on the client, for the presence of any items on the list. 18.A method of protecting digital media content from unauthorised use on aclient as claimed in claim 14 wherein the client ceases interaction withthe server, key management and playback of protected content if anyitems on the blacklist have been detected without passing any detailsrelating to processes running on the client to the server.
 19. A methodof controlling playback of digital media content on a client comprising:accessing a blacklist of items, determining presence of items on theclient that are on the blacklist, controlling playback of the digitalmedia content on the client based on the presence of items on theclient.
 20. A method according to claim 19 wherein the playback iscontrolled by aborting playback if at least one item on the client is onthe black list.